Industrial controllers are special purpose computers used for controlling industrial processes, manufacturing equipment, and other factory automation, such as conveyor systems. In accordance with a control program, the industrial controller measures one or more process variable or inputs reflecting the status of a controlled conveyor system, and changes outputs effecting control of the conveyor system. The inputs and outputs may be binary, (e.g., on or off), as well as analog inputs and outputs assuming a continuous range of values. The control program may be executed in a series of execution cycles with batch processing capabilities.
The measured inputs received from a conveyor system and the outputs transmitted to the conveyor system generally pass through one or more input/output (I/O) modules. These I/O modules serve as an electrical interface between the controller and the conveyor system, and may be located proximate or remote from the controller. The inputs and outputs may be recorded in an I/O table in processor memory. Input values may be asynchronously read from the controlled conveyor system by one or more input modules and output values are written directly to the I/O table by the processor for subsequent communication to the conveyor system by specialized communications circuitry. An output module may interface directly with a conveyor system, by providing an output from an I/O table to an actuator such as a motor, valve, solenoid, and the like.
During execution of the control program, values of the inputs and outputs exchanged with the conveyor system may pass through the I/O table. The values of inputs in the I/O table are asynchronously updated from the controlled conveyor system by dedicated scanning circuitry. This scanning circuitry may communicate with input modules over a bus on a backplane or network communications. The scanning circuitry also asynchronously writes values of the outputs in the I/O table to the controlled conveyor system. The output values from the I/O table are then communicated to one or more output modules for interfacing the conveyor system. Thus, the processor may simply access the I/O table rather than needing to communicate directly with the conveyor system.
An industrial controller may be customized to the particular process by writing control software that may be stored in the controller's memory and/or by changing the hardware configuration of the controller to match the control task. Controller hardware configuration is facilitated by separating the industrial controller into a number of control modules, each of which is performing a different function. Particular control modules needed for the control task may then be connected together on a common backplane within a rack. The control modules may include processors, power supplies, network communication modules, and I/O modules exchanging input and output signals directly with the controlled conveyor system. Data may be exchanged between modules using a backplane communications bus, which may be serial or parallel. A typical hardware modification may involve adding additional I/O modules in order to be able to control additional equipment.
Various control modules of the industrial controller may be spatially distributed along a common communication link in several racks. Certain I/O modules may thus be located in close proximity to a portion of the control equipment, and away from the remainder of the controller. Data is communicated with these remote modules over a common communication link, or network, wherein all modules on the network communicate using a standard communications protocol.
In a typical distributed control system, one or more output modules are provided for interfacing with a process. The outputs derive their control or output values in the form of a message from a master or peer device over a network or a backplane. For example, an output module may receive an output value from a processor, such as a programmable logic controller (PLC), via a communications network or a backplane communications bus. The desired output value is generally sent to the output module in a message, such as an explicit message or an I/O message. The output module receiving such a message will provide a corresponding output (analog or digital) to the controlled process.
Control systems are often employed in association with conveyor systems for moving objects along guided tracks, including modular conveyor sections or “sticks”. Conveyor systems for moving objects between stations in a manufacturing environment or for accumulating and distributing products in a warehouse operation are well known in the art. Such conveyor systems provide upwardly exposed conveying surfaces, such as rollers, positioned between guiding side rails. The rollers are powered by controllable motors to move objects placed on top of them along a track defined by the rails.
Assembly of conveyor systems is facilitated by the use of “conveyor sticks” which may include one or more short sections of rollers and guide rails, which are connected together to form the final conveyor system. The conveying surface of each conveyor stick may be broken up into one or more zones, each associated with a sensor for detecting the presence of an object on the conveyor at the zone. A control circuit communicates with each zone and sensor via a number of cables to control the zones, in order to accomplish a number of standardized tasks.
Such conveyor systems may be adapted to perform one or more tasks or operations. One such task is that of “accumulation” in which a control circuit for a given zone operates its rollers when the sensor, in an upstream zone, indicates an object is at that zone and the sensor of a “downstream” zone indicates that no object is in that downstream zone. This logic causes the conveyor zones to move objects along to fill all zones with objects. In a “slug release” operation, each control circuit in a defined release zone operates its rollers if its sensor indicates an object is present and no object is in the downstream zone from the defined release zone. This logic causes the emptying of a predefined section of the conveyor, typically to a downstream portion. A third mode of operation is “singulation release” in which a single object at a time is unloaded from the conveyor system. Each upstream control circuit operates its rollers to move its objects downstream one zone.
In order to perform these tasks, the control circuit for a particular conveyor stick may communicate in a limited fashion with the control circuits (or at least the sensors) of associated upstream and downstream conveyor sticks. This may be accomplished via cabling between control cards or sensors of the conveyor sticks, typically within one of the side rails. The conveyor system may operate without the need for a central controller, for example, such as where one or more I/O points are provided for each zone, thus reducing the wiring associated therewith. By eliminating the need for such wiring, the conveyor sticks can be easily assembled or reconfigured. Nevertheless, the lack of central control makes the conveyor system relatively hard to reconfigure requiring, for example, settings to being manually adjusted on each controller board when delay times and conveyor speeds are changed. Further, lack of centralized communication between components of the conveyor system makes it difficult to detect and report conveyor system problems such as motor failure or material jamming.
Some conventional control devices and systems for such conveyor systems provide outputs solely based on messages from a network, having no internal logic. For example, such a device may provide an output according to an output value received in an I/O message from a master (e.g., a PLC), and may maintain that value during normal operation until another message is received. In some such devices, certain conditions can affect the output value. For instance, when a module detects a communications fault, the output may go to a known state. However, there are many sources that may affect an output point's value. These include an I/O message, an explicit message, local logic, fault or idle values, and/or a forcing message. Heretofore, the source of an output value was determined according to fixed controller architecture constraints. Thus, a user had limited ability to decide priorities for the source of a conveyor system output module's output value. In addition, there are many conditions or events associated with conveyor systems for which it may be desirable to provide another output value to the device. Heretofore, a user had no ability or a limited ability to define output device behavior in lieu of regular I/O messages.
In addition, some conventional conveyor control devices provide a run mode wherein a module executes a control program and a configure mode wherein the control program execution is suspended. As conveyor control systems become more widely distributed, the logic or control program associated with a particular system may be executed on a large number of modules or devices. In this way, individual processors in the devices execute a program autonomously from the rest of the system components. Smart devices, such as I/O modules, transducers, sensors, valves, and the like may thus be programmed to execute certain logical or other programs or operations independently from other such devices.
The distribution of smart devices in a networked conveyor control system has many advantages. However, system testing and troubleshooting are often more difficult in distributed systems. In a system with many autonomous smart devices, each having its own control logic or program, problems in system performance cannot easily be traced to a specific device. Once the component devices in such a system are placed into execute or run mode, the logic or control programs associated therewith run independently, and are often not synchronized. Even where certain conveyor control devices in a system are synchronized to certain events, determining the source of a system control problem is still difficult.
In many cases, the source of a control problem is an error in programming a particular module. For example, the logic function in a particular module may be the function of several input values or states. Problems in the logic function may only be discernable in one or a small number of input combinations. In widely distributed conveyor control system architectures, system events occur asynchronously, such as I/O value state changes, messages, etc. Thus, when a problem occurs, it may be difficult to determine the source of the error.
This is particularly problematic in system startup situations. Large conveyor control systems are typically tested before application to a real process, with inputs simulated and outputs tested under a variety of input conditions. In addition, control system diagnostics are needed in the field, when problems in system performance are recognized, or when system parameters are changed. Present diagnostic tools are typically limited to simulating input signals and monitoring output values. Conventional control devices do not provide for ease of troubleshooting in such distributed conveyor control system applications.